The present invention relates to methods of executing computer processes and, more particularly, to methods of remotely executing computer processes.
Remote execution involves the execution of a computer process at a processor site other than the one initiating the process. In general terms processes may be regarded as including various actions such as the execution of a computer program, invocation of a system service or an interaction with a user. The computer initiating the remote execution is typically called the parent. The remote computer actually executing the process is normally referred to as the child. An example of remote execution is the situation where a user employs a home computer to run a program on another computer, such as a work station, back at the office.
Remote execution is advantageous in a variety of circumstances such as, for example, when hardware requirements dictate use of a more sophisticated remote processor. Remote execution can also be beneficial in instances where data or software transmission time and costs exceed those associated with simply operating the child computer remotely. If, for example, a user at home wished to work on a large database resident at a work station back at the office, the cost of transmitting the entire database to the home computer could be avoided by instead remotely executing the database software at the office work station. In some instances software licensing restrictions may also dictate that a process be executed at a specific computer site having a duly authorized copy of the software. The office work station may, for example, have a licensed version of an expensive commercial software package installed. Installing the same software on the user""s home computer, however, might be a violation of the software license agreement unless another copy of the software is purchased for the home computer.
It is normally desirable for remote execution of a process to be network transparent. That is, the user at the parent computer should be able to run a program on the child computer in the same way as if the program were running on the parent computer, and should be able to obtain the same results. In some instances an opposite effect may be desired, so that remote execution of a process at a child computer is explicitly apparent to the user. This latter situation is termed non-transparent remote execution. In still other circumstances some aspects of the process preferably appear the same to the user (as if the process were running at the parent computer instead of at the child computer) while other aspects of the process should explicitly reflect their remote execution. This type of remote execution is usually termed semi-transparent. A semi-transparent type of remote execution may be desired, for example, when a user at their home computer wishes to execute a command at a computer site or location other than the home or office, but still make use of resources that are resident at the home or office computer and absent from the remote site of process execution.
During either local or remote execution most processes typically access various objects such as files, devices and system services. These objects are normally accessed through some form of representation, typically referred to as their name. An object name is commonly thought of as being bound to the object accessed through that name. In the case of transparent remote execution, objects are accessed through same representations, or names, irrespective of whether the process is being executed remotely at the child computer or locally at the parent computer. In the case of semi-transparent remote execution, at least some objects (involving those aspects of the process that are to appear the same to the user) are preferably accessed through the same names during either local execution at the parent computer or remote execution at the child computer.
In most distributed systems there is commonly a set of objects resident at each computer in the system. Each computer may, for example, employ the same operating system or word processing software package. Such objects are normally termed generic. During remote execution of a process on a child computer it is generally desirable for the remote process to access the generic objects resident at the child computer directly from the child computer. At the same time other objects, resident only at the parent computer, should still be accessed from the parent. Some objects such as data files may reside only at the parent computer. Accessing generic objects at the site of execution is usually regarded as more efficient, since the object need not be transferred from the parent computer to the child computer. Accessing other non-generic objects from the parent computer provides the desired name transparency for remote execution that is to be of the transparent or semi-transparent form. Unfortunately, however, most conventional naming schemes do not easily facilitate transparent or semi-transparent forms of remote execution that permit accessing objects from more than one computer site.
A majority of conventional computers typically employ a per-system naming scheme. Each computer has its own hierarchical naming tree containing component names through which objects are accessed. A particular document in a DOS based personal computer, for example, might be accessed through the name xe2x80x9cc: doc.1xe2x80x9d. The same name, however, may represent separate objects on separate computers. By way of example office-coworkers may have different versions of the same document on their respective computers. While each version of the document is a separate object, both of these objects may have the same xe2x80x9cc: doc.1xe2x80x9d name. Accordingly per-system naming schemes normally can only access objects resident at either the child computer or the parent computer, but not both. Thus per-system naming schemes generally are not sufficiently flexible to facilitate the most useful forms of transparent and semi-transparent remote execution.
An alternative to per-system naming schemes are the per-process naming schemes. In per-process naming schemes each computer process has its own set of name-to-object associations, or name bindings. These bindings are again typically organized in a hierarchical naming tree. Each computer on which a process is executed may also have a set of name bindings organized in a naming tree. The naming tree of a computer is normally attached to the naming tree of those processes that are executed on that computer. While each process normally has its own independent set of name bindings, many bindings may be shared between processes. One example of a per-process naming scheme is the EPort distributed environment, developed in part by the inventor herein. In the EPort environment computers are grouped into divisions. There is normally a high degree of sharing between computers within a division, but limited sharing across divisions. Each computer in the EPort environment possesses its own set of name bindings for objects resident at that computer, typically organized in a hierarchial naming tree. Each division has also its own hierarchial naming tree for objects that are shared among the computers within that division. Each process in EPort has its own root node to which it attaches the naming trees of various subsystems, such as the naming trees of individual computers and divisions. Typically, an EPort process attaches the naming tree of the computer and division within which the process resides. An EPort process can also attach the naming trees of other subsystems during remote execution.
Transparent and semi-transparent remote execution may normally be performed using per-process representation schemes such as EPort. During remote execution the set of name bindings of the parent process at the parent computer is passed to the child process at the child computer. Some changes, however, are made in the copy of the parent name bindings transferred to the child. The name bindings of some objects, such as the bindings of objects generic to both the parent and child computers, are changed to point to the child computer. That is, the name bindings of these objects are changed so that the objects may be accessed by the child process directly from the child computer, rather than from the parent computer. The name bindings to be changed may be specified in one of several ways. One method of specifying the desired name changes involves maintaining a list of objects in an appropriate system, such as a remote execution server. For example, a list of generic objects may be maintained in this fashion so that generic objects are always accessed from the site of process execution, whether the process is executed locally at the parent computer or remotely at the child computer. As an alternative method of specifying desired name changes, a user may explicitly designate any additional objects that should be accessed at the child computer through changes to the name bindings of the parent process. That is, the user may expressly make the changes to the name bindings his, or her, own self.
Regrettably, conventional per-process naming schemes still suffer from a number of disadvantages relating to remote execution. If the names of generic objects are changed, or if new generic objects are added to the parent and child computer systems or older generic objects deleted, then the data files of the remote execution server must be altered to reflect these changes. Alternatively, the user must specify the required changes in the set of objects to be accessed by the child process by remote execution. Changes in the set of generic objects are usually found to occur as a distributed computing system evolves. These changes, however, are normally viewed as non-trivial and highly inconvenient. Changes to the data files of a remote execution server are undesirably burdensome for system administrators. User specified changes are, in turn, viewed as a considerable burden to users who are not sophisticated computer experts.
Thus, there still exists a need for an improved method of implementing remote process execution that facilitates transparent and semi-transparent execution, but does not require modification of the remotely executing process or modification of remote execution servers, as objects in a distributed computer system are added, deleted or changed. The present invention finally fulfills this need.
Broadly, and in general terms, the present invention provides a method of remote execution that greatly facilitates transparent and semi-transparent execution. Additionally, generic objects may be accessed by a remotely executing process at the remote site of process execution while objects resident only at the parent computer are still accessible to the remotely executing process. All of these goals are achieved without requiring modification to distributed system level services, such as remote execution servers, whenever sets of generic objects are added, deleted, or otherwise modified. The invention is applicable to any system that supports remote execution. The invention may be applied between two or more computers whether or not the computers are part of a network and may also be applied to parent and child computers residing in different networks.
In accordance with one embodiment of the present invention generic objects and the like are associated with representations, or names, having specific object bindings dependent upon the computer site of process execution. While the name associated with an object remains constant, the specific object binding for that name changes depending on which computer is executing the process. The same name may have a first object binding if the process is executed on the parent computer, but a different object binding if the process is executed on the child computer. The objects associated with these execution site dependent names include objects having instances, or copies, that are resident on both the parent and child computers. The present invention thus facilitates transparent and semi-transparent remote execution by providing a method through which processes may obtain generic objects and the like from the site of process execution without requiring additional changes to the representation, or name, of the objects while still allowing access to other objects from the parent computer so as to provide a desired degree of transparency.
The method of the invention may also be applied to parent and child computers residing in different networks. In the case of remote execution across computer networks some of the objects accessed by a process during execution typically reside at both the local and remote network server. These objects may be termed network generic. In accordance with another embodiment of the present invention, appropriate objects are associated with names having object bindings dependent upon which network includes the computer executing the process. This second set of objects may include network generic objects. Advantage may then be taken of both the processor generic objects resident at both the parent and child computers as well as the network generic objects resident at both the parent and child networks. In this embodiment processes executing remotely at the child computer can locally access both network and computer generic objects.
In yet a further embodiment of the invention appropriate objects are associated with an ordered merger directory including representations having object bindings depending on, and pointing to, the site of process execution. Objects in this third set are then accessed either directly from the computer site of remote process execution, or from processor sites proximate the site of process execution. An ordered merge directory provides multiple representations through which an object may be accessed, each representation usually having a different object binding. If an object can not be accessed through a first representation in an ordered merge directory, further representations may be utilized until the object is successfully obtained.
The invention may be implemented by, for example, a process execution server operating with a per-process naming scheme. In operation a copy of a parent context is made by the execution server when a process is to be executed. This copy of the parent context may be termed the child context. The process to be executed may be termed the child process. The parent context includes at least one representation referring to a local processor site. This local processor site representation has an object binding that is changed dependent on the site of process execution. Initially this local processor site representation is bound to the parent computer. After the child context, the copy of the parent context, is made a determination is made by the process server as to whether execution of the child process is to occur locally at the parent computer or remotely at the child computer. If execution is local at the parent computer, the child context is simply passed to the child process. If execution is to be remote at the child computer, the object binding of the local site representation in the child context is changed to point to the child computer at which the process will be remotely executed. A context of the child computer is also added to the child context. This changed and supplemented child context is then passed to the child process that is being remotely executed at the child computer. If remote execution occurs across networks, changes are also made in the child context to a representation referring to the local network site of the process execution. This local network site representation is also changed to point to a network server of the child computer""s network. A copy of the child""s network server context is also added to the child context.
The present invention thus provides a method of transparent and semi-transparent remote execution between a parent computer initiating a process and a child computer executing the process. Processes remotely executed in accordance with the present invention are further able to access objects at sites hierarchically proximate the site of remote process execution. Modification of remote execution servers or other administrative level system services is not required each time objects are added to or deleted from the parent and child computers or their respective networks, or when object names are changed. Still further goals, objects and aspects of the present invention will be better understood by review of the figures herein, and the following detailed description of the invention.